In general, there are only two forms of a data object in a program, instances and references. An instance is the actual data object, and can be created statically by the compiler or dynamically by the application. A reference occurs when a function accesses a data object whose instance was created elsewhere (usually in another function).
Ordinarily, all programs are comprised of one or more functions. Larger programs may have the sources for many of the functions stored in separate files for convenience of maintenance and to reduce compile time. Since the source for these large programs are stored in separate files, they are compiled into relocatable object files (i.e., “.” files) that have one-to-one correspondence with their source file. The compilation of these source files into the relocatable object files has a temporal nature. A relocatable object file derived from one source can be produced one month and a relocatable object file derived from another source file can be produced in another month. A resulting program can then be constructed by linking two relocatable object files at a third time without compromising the correctness of the program. This linking without compromising the correctness of the program is provided on the condition that none of the source files are changed between the compilation of the first source file and the compilation of the second source file.
This utilization of the relocatable object file derived from one source that can be produced in one month and accessed and re-utilized in other modules at a later time normally will not have address range or alignment errors caught by the linker. This is especially true during the development of the multiple code modules, in that the program can then have a high failure rate during execution. Therefore, there is a need for the developers to have the ability to have address range or alignment check performed at run-time to ensure run-time program correctness. This address range or alignment checking is needed because of inconsistent references to objects that change over time.
There is also a great need to make this address range or alignment check temporary, because once the developers have ensured the run-time correctness of the program then the additional overhead caused in space or time to perform this run-time checking need not be performed on an ongoing basis when the program is in normal production or is being utilized by the end user.
There is also the need to have the run-time address range or alignment checking performed on an as needed basis (i.e. switchable) should errors occur during normal operation. This switchable run-time checking would then allow for the debugging of the program modules at a later time by switching the run-time checking to an “on” mode to assist in debugging of the programs. In order to have this switchable, there is a need to allocate the space required for a methodology to perform the run-time address range or alignment checking at any time desired.
However, if one of the relocatable object files is produced from a first source, and a data object declaration in a second source that is used by both of the source files is changed in the common header file, a second relocatable object file is produced from the second source file. Then the two relocatable object files will contain data object declarations that are incompatible, but not detectably different.
From the foregoing, it can be appreciated that it would be desirable to have a system and method for preventing software errors caused by address range or alignment errors.